Summary

• Wraps connectToRabbitMQ() in suites/tracing/amqplib/scenario.mjs with a 5-attempt, 1-second-backoff retry loop. First attempt is unchanged; only retries trigger on connect rejection.

Root cause

From the failing run:

FAIL suites/tracing/amqplib/test.ts > amqplib auto-instrumentation > esm/cjs > esm > should be able to send and receive messages
Error: Expected envelope item type 'transaction' but got 'event'.
Item: [{"type":"event"},{"exception":{"values":[{"type":"Error","value":"Socket closed abruptly during opening handshake", ...

The docker-compose healthcheck (rabbitmq-diagnostics -q ping) reports the broker ready before its AMQP listener can complete the protocol handshake. So:

1. Healthcheck passes → runner launches the scenario.
2. await amqp.connect(AMQP_URL) rejects with Socket closed abruptly during opening handshake.
3. The rejection isn't caught by the top-level IIFE → OnUnhandledRejection integration captures it → Sentry sends it as an error envelope.
4. The runner's strict envelope-stream parser (utils/runner.ts:509) sees an event where it expected a transaction and throws.

Fix

Add a retry loop around amqp.connect + createChannel. The first attempt path is unchanged (no extra latency in the common case). On transient connection rejection, retry up to 4 more times with 1 s spacing — total worst-case extra time 4 s, well within the test's 60 s timeout. After 5 failures, throws lastError (same failure mode as today, just delayed).

Connection retry is the industry-standard pattern for broker-readiness races where the healthcheck reports a coarser signal than the actual protocol. The change is purely additive — first-attempt success is unchanged, assertions are unchanged, and a truly broken broker still surfaces as a scenario failure.

Fixes #20969

🤖 Generated with Claude Code